ci: exercise BUILD_PACMAN_CLIENT=ON in its own job - #152

The published cores are moving to a glibc-2.31 build base; building the
packaging-validation job in the same container proves that recipe in CI
before publication depends on it. focal needs pip for cmake and meson
(its own predate the package client's floors), and the bundle download
moves from gh to plain curl since the container ships neither.

stage1, the Linux stage-2 legs and the pacman-client job now run in the
same glibc-2.31 base the published cores are moving to, so the whole
Linux half of the matrix validates what users actually receive. The
containers ship no git, and a checkout without it silently degrades to
a tarball with no .git, which broke the revision probe at configure --
git is installed before the checkout. Stage 3 stays on the runner: its
outputs are Windows and FreeBSD binaries that no glibc floor touches,
and its build tools come from the stage-2 SDK, which runs fine there.

The revision probe passes COMMAND_ERROR_IS_FATAL, a 3.19 feature, while
the declared minimum said 3.16 -- focal's apt cmake exposed the lie.
Declare 3.19 and give the containerized stage legs the same pinned pip
cmake the pacman-client job already uses.

The workspace mount belongs to the runner uid while the container runs
as root, and focal's git carries the safe.directory backport, so every
git probe after checkout refused the repository.

A containerized job cannot drive the packaging tests: the docker CLI is
absent and a sibling container's mounts resolve against the host, not
the job container. Same answer as the musl legs: the job stays on the
runner, only the build and the toolchain contract enter ubuntu:20.04 --
which is also exactly the shape autobuilds uses to publish, so the job
validates the real thing. The revision and epoch travel in as -D values
the way autobuilds passes them, sparing the container any git probing
of the runner-owned checkout.